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[57] ABSTRACT 

The present invention is a general solution to the prob- 
lem address incompatibility between application pro- 
grams and transport services. The invention may be 
embodied in a method for mapping the application pro- 
gram address (program address) to the transport ser- 
vices address (transport Provider address). According 
to the method, a program address is registered in the 
network so that it becomes available to other programs 
that understand the address, even if they are running 
over a transport protocol that does not understand the 
address format When a request is made that a connec- 
tion be established between a program and a program 
partner or that a datagram be sent therebetween, the 
program address is mapped to the transport Provider 
address (if necessary). The program address is then 
conveyed to the program partner so that it knows who 
it is talking to. 

18 Claims, 30 Drawing Sheets 
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PROTOCOL SELECTION AND ADDRESS 
RESOL UTION FOR PROGR AMS RUNNING IN 
HETEROGENEOUS NETWORKS 

5 

This application is closely related to oar own, com- 
monly assigned U.S. Pat No. 5,224,098, having an issue 
date of Jun. 29, 1994, entitled "Compensation for Mis- 
matched Transport Protocols in a Data Communication 
Network". The patent describes a Multi-Protocol 10 
Transport Networking (MPTN) Architecture which 
allows an application program running at one node in a 
network to communicate with a second application 
program running at another node in the network even 
where the application programming interface (API) IS 
assumes a different set of transport functions than those 
supported by the transport provider. In particular, it 
relates to a method for establishing communication, 
either connectionless or with a connection, between the 
applications and compensating for transport protocol 20 
mismatches, if any. The present invention relates to 
address resolution and protocol selection among multi- 
ple transport protocols for the applications and the 
nodes in the MPTN. 

BACKGROUND OF THE INVENTION 25 

I. Field of the Invention 

The present invention relates to data communications 
and more particularly to methods of resolving address- 
ing differences between applications and networking 30 
protocols and for selecting from a choice of networking 
protocols when multiple protocols are available. 

II. Prior Art 

As communications networks have evolved, indepen- 
dent suppliers of computer hardware and software de- 35 
veloped different, non-compatible formats and proto- 
cols for transporting data through the communications 
networks. Examples of well-known communications 
protocols include System Network Architecture 
(SNA), Digital Network Architecture (DECnet), 40 
Transmission Control Protocol/Internet Protocol 
(TCP/IP), NetBIOS and OSI. 

As networks have grown, and particularly as local 
area networks have come into widespread use, many 
organizations have ended up with confederations of 45 
individual networks running different networking pro- 
tocols. For example, a single organization may have 
dozens of networks running as many as four or five 
different networking protocols. This heterogeneity 
complicates the network communication as distributed 50 
programs are generally written for a particular applica- 
tion programming interface (API) which assumes a 
specific networking protocol, and can, therefore, only 
run on limited parts of the overall network. 

If a mismatch exists between the transport protocols 55 
(the most basic end-to-end networking protocols for 
opening and closing connections, sending and receiving 
data on connections, and sending and receiving data- 
grams) assumed by the particular API for a company's 
application program and the transport protocols actu- 60 
ally implemented in one or more of the networks on 
which the company would like to transport the applica- 
tion data, compensation between the API and the net- 
work may be required. This is described in greater de- 
tail in closely related issued U.S. Pat No. 5,224,098. 65 

In addition, there are addressing problems associated 
with the heterogeneous networks. A program today 
identifies itself and finds its partners using addresses 



associated with a particular networking protocol (A 
networking protocol uses addresses to locate programs 
in the network via existing protocol-specific means, 
such as local directory searches or directory broadcasts 
and to route to those programs.) In order for the pro- 
gram to operate over multiple, different networking 
protocols, a mechanism is needed to bridge the gap 
between the specific address set used by the program 
and the address sets used by the networking protocols. 
In particular, program independence from specific net- 
work protocols requires a transport-independent mech- 
anism for finding the source and destination application 
programs and the corresponding available transport 
protocols. In addition, a mechanism for selecting the 
best transport protocol to utilize, when multiple net- 
working protocols are available, is required. 

Since many programs already exist using existing 
address formats, it is not feasible to require all pro- 
grams, including those in existence, to use a single stan- 
dard address format Likewise, it is not feasible to 
change all existing transport protocols to support the 
complete list of address formats used by application 
programs or to use a single standard format 

The work described here is different from that de- 
fined in the TCP/IP Requests for Comments (RFCs) 
1001 and 1002 in that the RFCs solve the problem for a 
specific transport user and transport provider, but do 
not address the general mechanism needed to support 
many different types of users or providers. The work 
also differs from an application directory, such as OSI's 
X.500, in that its dynamic nature is more akin to a net- 
working directory and it does not deal with name to 
address mapping with their associated complexities. 

In addition, where a source application program is 
able to communicate with a destination partner pro- 
gram over one of multiple transport providers, the most 
efficient provider should be chosen. At present, no 
method of selecting the best transport provider based 
on services provided when more than one are available 
is known. 

SUMMARY OF THE INVENTION 

The present invention is a general solution to the 
problem of address incompatibility between application 
programs and transport services. The invention may be 
embodied in a method of mapping the application pro- 
gram address (program address) to the transport ser- 
vices address (transport provider address). According 
to the method, a program address is registered in the 
network so that it becomes available to other programs 
that understand the address, even if the transport-level 
communication is over a transport protocol that does 
not understand the program address format. When a 
request is made that a connection be established be- 
tween a program and a program partner or that a data- 
gram be sent therebetween, a transport provider is se- 
lected to minimize compensation required and the pro- 
gram address is mapped to the transport provider ad- 
dress (if necessary). The program address is then con- 
veyed to the program partner so that it knows to whom 
it is talking. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the tfrhnical description concludes with 
claims particularly pointing out and distinctly claiming 
that which is regarded as the invention, details of a 
preferred embodiment of the invention may be more 
readily ascertained from the following technical de- 
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scription when read in conjunction with the accompa- system 26 through which an application program 14 in 

nying drawings, where: access node 10 may exchange data with an application 

FIG. 1 is a block diagram of a two-node computer program in access node 12. 
network, showing the functional representations of Referring first to access node 10, the application pro- 
major elements of the present invention. 5 gram 14 communicates with the remainder of the net- 

FIG. 2 is a diagram showing a possible logical config- work by sending and receiving commands and data, 

uration of an MPTN access node, frequently referred to as primitives. The primitives are 

FIG. 3 is a flow diagram showing the logic flow of provided by the application programming interface or 

the Local Control Function in an MPTN access node API that was employed in writing the application pro- 

during the protocol preference selection process. 10 gram. 

FIG. 4 is a diagram showing possible contents of the The primitives flow to and from a transport user 18, 

Address Registry of the present invention. the role of which is to convert application primitives to 

FIG. 5 is a high level flow diagram showing the logic standard representations referred to as transport layer 
flow of the Local Control Function in an MPTN access protocol boundary (TLPB) functions. The TLPB con- 
node during the registration/deregistration process of a 15 tains verbs which perform major transport functions 
user address. such as opening connections, sending and receiving 

FIGS. 5A through 5F illustrate the same logic flow in data and closing connections. Most application pro- 
greater detail, grams need only a limited set of TLPB functions. If the 

FIG. 6 is another high level flow diagram showing application program is written directly to the TLPB, 
the logic flow of the Address Registry responding to 20 the transport user function would be integrated into the 
messages from an access node or a transport gateway application program. The TLPB functions are de- 
during the registration/deregistration process of a user scribed for completeness of disclosure but are not re- 
address, quired for the implementation of the present invention. 

FIGS. 6A through 6E illustrate the same logic flow Transport user 18 may be logically linked to an 

in greater detail 25 MPTN manager 19. The transport user and the MPTN 

FIG. 7 is a high level flow diagram showing the logic manager will operate under the control of a control 
flow of the Local Control Function in an MPTN access point 22 in node 10. The MPTN manager 19 is tied to 
node during the establishment of a connection or the the communication system 26 through a transport pro- 
conveyance of a datagram between two program part- tocol stack or transport provider 24. 
ners - 30 Transport provider 24 defines the transport protocols 

FIGS. 7A through 7E illustrate the same logic flow that are actually implemented when the data is ex- 

in greater detail. changed between the two nodes over the communica- 

FIG. 8 is a high level flow diagram showing the logic tion system 26. Examples of transport providers are 

flow of the Address Registry during the establishment layers 1-4 of OSI, NetBIOS, and TCP/IP. 

of a connection or the conveyance of a datagram be- 35 The MPTN manager 19 may comprise a protocol 

tween two program partners. compensator (PC) 20 and a local control function 

FIGS. 8A and 8B illustrate the same logic flow in (LCF) 21. Protocol compensator 20 compensates for 

greater detail. mismatches between the protocol followed by a TLPB 

FIG. 9 illustrates the basic format of an MPTN mes- verb and the protocol followed by a corresponding 

sage of the present invention. 40 verb or function in transport provider 24 and vice versa, 

FIG. 10 illustrates the format of an MPTN Connect It is in this way that the differences between the trans- 
message of the present invention. port protocol to which the application was written to 

FIG. 11 illustrates the format of the prefix field of an and the actual transport protocol are compensated for. 

MPTN message of the present invention. This is described in great detail in related copending 

FIG. 12 illustrates the format of the User Transport 45 application Ser. No. 07/731,564. 

Req field of an MPTN message of the present invention. Local control function 21 supports non-native con- 

FIG. 13 illustrates the format of the Service Mode nections or datagrams to and from the node by perform- 

field of an MPTN message of the present invention. ing address registration, protocol selection and address 

FIG. 14 illustrates the format of the Diagnostics Data resolution. This will be discussed in greater detail be- 

field of an MPTN message of the present invention. 50 low. 

FIG. 15 illustrates the format of an MPTN Datagram MPTN access node 12 contains its own transport user 

message of the present invention. 34, MPTN manager 29, protocol compensator 30, local 

FIG. 16 illustrates the format of the Segment Spec control function 23, control point 32 and transport pro- 
Data field of an MPTN message of the present inven- vider 28. These components perform the same basic 
ti° n - 55 functions as the corresponding components in node 10. 

FIG. 17 illustrates the format of an EA Register mes- As can be seen, the computer network further corn- 
sage of the present invention. prises an address resolution service 25 connected to the 

FIG. 18 illustrates the format of the Correlator field communications system 26. Address resolution service 

of an MPTN message of the present invention. 25 is accessible by all nodes connected to communica- 

FIG. 19 illustrates the format of the Address List 60 tions system 26 and provides a multi-protocol Address 

field of an MPTN message of the present invention. . Registry 27 for the network. This, also, will be dis- 

DETAILED DESCRIPTION OF THE °T^Jf ^ ^ ' „ ♦ 

PREFERRED EMBODIMENT order to ^hsh a connection or to send data- 

grams, proper addresses must be used, both within the 
FIG. 1 is a high-level block diagram of a simple com- 65 node and within the network. For instance, a transport 
puter network consisting of a first multi-protocol trans- user conforming to a particular transport protocol, e.g., 
port network (MPTN) access node 10, a second MPTN OSI, uses a particular addressing scheme. Likewise, a 
access node 12 and an intervening communications transport provider cortfonning to a different protocol, 
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e.g., SNA, has different addressing characteristics. Am- gram services. The lists are ordered based upon the list 

biguities or mismatches between the different ("non- of available transport protocols in the node and the 

native") schemes must be resolved so that communica- transport characteristics requested by the program. For 

tion may take place. example, if a program requests expedited data service, 

In contrast, an SNA transport user and an SNA pro- 5 the local control function arranges the preference list so 

vider have no addressing ambiguities or mismatches as that transport protocols that support expedited data 

they are ''native" to one another. natively are preferred over those that do not 

In an MPTN access node, there may be a number of FIG. 3 is a flow diagram showing the logic flow of 
application programs, a number of different users, and a the Local Control Function in an MPTN access node 
number of different providers. For example, in FIG. 2, 10 during the protocol selection process. At step <K, a 
a possible logical configuration of an MPTN access registration list for the particular transport user is ore- 
node 27 is shown. In this case, MPTN access node 27 is ated containing a transport provider node address for 
supported by two providers, SNA 29 (logical unit (LU) each transport provider the transport user can use. If 
a) and OSI 31 (node service access point (NS AP) a), there are no limitations, the node preference list is used, 
and has two users, OSI 37 (NSAPb) and TCP 39 15 At step 67, the Local Control Function insures that all 
(NET.HOST). Each user supports a number of pro- transport providers that the particular transport user 
grams, OSI 37 supporting programs identified by *T- can use have been added to the transport user's connec- 
selectors" 43, and TCP 39 supporting programs identi- tion preference list At step 69, the Local Control Funo 
fied by "ports" 45. As discussed above, each of these tion identifies the required compensations for the next 
different application programs was written for a differ- 20 transport provider that this transport user can use by 
ent API and, therefore, each has different addressing comparing the transport user's characteristics to the 
formats and identifiers. Likewise, the users have differ- transport provider's characteristics. At step 71, the 
ent addressing formats and identifiers. Local Control Function, calculates a measure of com- 

In addition, MPTN access node 27 has an MPTN pensation effort in assigning an effort weight to each 
Manager 19, as previously discussed. MPTN Manager 25 compensation and summing the weights. At step 73, this 
19, among other things, must keep track of which appli- transport provider is added to the transport user's con- 
cation programs are locally active, i.e., which programs nection preference list so that it precedes transport 
are registered for sending and receiving datagrams or providers with higher compensation measures and fol- 
for being connected with partner programs. This is lows those with lower or equal compensation measures, 
done by local control function 21. 30 An example of the protocol selection process is illus- 

The local control function 21 accomplishes this by trated in the following Tables 1, 2 and 3. Table 1 illus- 

keeping track of the various addresses of the different trates four compensations, e, f , g and h, and their respec- 

local users in its own local directory. For instance, if tive effort weights, 1, 1, 2 and 2. As noted above, the 

programs with five T-selectors 43c, 436, 43c, 43d, and effort weight associated with each of the compensations 

43e are registered for communication, local control 35 is a measure of the effort required to provide compensa- 

function 21 keeps track of the programs in a local direc- tion between the transport user and the transport pro- 

tory with the user address, OSI NSAPa, and the pro- vider. For example, compensation e with an effort 

gram addresses, T-selectors 43c, 436, 43c, 43o*, and 43e. weight of 1 takes less effort than compensation g with 

In a similar manner, the local control function can keep an effort weight of 2. 

track of active TCP programs with ports 45 with their 40 Table 2 illustrates four example protocols, A, B, C 

user address, TCP NET.HOST. The generic term to be and D, and the compensations required by each of the 

used in this document to describe the program addresses particular protocols. For instance, protocol A requires 

maintained by the local control function is **programid" compensations e and f, protocol B requires compensa- 

so that the programid for T-selector 43a is "T-selector- tions g and h, protocol C requires compensation g, and 

43a, NSAPa" (program identifier with user identifier). 45 protocol D requires all four compensations, e, f, g and h. 

If the transport provider and the program (or user) Table 3 illustrates the preference list for the protocols 

use the same address type, the program is said to be A, B, C and D in accordance with the protocol selec- 

**native" to the transport provider. In the example tion method of the present invention. In particular, 

shown in FIG. 2, T-selector 43a and transport user OSI protocol A, which requires compensations e and f hav- 

NSAPa 37 are native to transport provider OSI NSAPa 50 ing effort weights, respectively, has an overall 

31. Where a native program is to communicate, the weighting of 2. Protocol B, which requires compensa- 

transport provider conveys the address and no address tions g and h, having effort weights of 2 and 2 respec- 

mapping or address resolution is necessary. Shnilarly, tively, has an overall weight of 4. Protocol C which 

no compensation is required. requires compensation g, having an effort weight of 2, 

A program is , *non-native" with respect to a particu- 55 has an overall weight of 2. Finally, protocol D, which 

lar transport provider if it uses different address types requires compensations e, f, g and h, having effort 

than the transport provider or if it requires transport weights of 1, 1, 2 and 2, respectively, has an overall 

characteristics that require compensation over the weight of 6. The order of the preference list is from the 

transport provider. Where a program is running over a least total effort weight to the greatest total effort 

non-native protocol, such as T-selector 43a running 60 weight In the present example, the preference list has 

over provider SNA 29, address mapping is necessary. the order of protocol A, protocol C, protocol B and 

Where a program (and user) is supported by a number then protocol D, so that where a particular transport 

of providers, the local control function determines user with characteristics requiring the compensations 

which of the providers is best suited for conveying the listed in Table 2 is serviced by each of the four proto- 

information. The local control function maintains one 65 cols A, B, C and D, protocol A would be chosen to 

or more connection preference lists and datagram pref- provide the particular service. Where a particular trans- 

erence lists, i.e., lists in preference order of the provid- port user with characteristics requiring the compensa- 

ers that could potentially provide connections or data- tions listed in Table 2 is serviced by only protocols C 
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and D, the Local Control Function would select proto- 
col C for providing the service. 

TABLE 1 
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Effort Wt 
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1 + 1=2 
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2 + 2 = 4 
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1+1+2+2=6 
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For many protocols, such as SNA and OSI, addresses 
consist of a provider identifier and a local identifier. 
The provider identifier identifies the particular provider 
which is servicing the program while the local identifier 

specifies where in the node the program is located. try, determine what type of and which particular pro- 
Other protocols, such as NetBIOS, do not utilize two- 30 vi ders ^ hp 
part addressing schemes. 



when the transport user (via the local control function) 
registers its address. This makes the transport user ac- 
cessible to other transport users in the network. The 
address resolution service 25 verifies the uniqueness of 
the address if the transport user address type requires 
dynamic verification of uniqueness (e.g., as in 
NetBIOS). 

When it becomes active, a program registers its ad- 
dress via the local control function. It may register as an 
individual (for receiving messages from partner pro- 
grams on an individual basis) and it may associate itself 
with a group address in order to receive multicast dia- 
grams. For various non-native transport protocols to be 
used, the control function sends Register messages to 
the associated Address Registry in order to register the 
program address so that it can be located by partner 
programs over the non-native transport protocols. Each 
Register message includes the user address and the pro- 
vider address for each transport protocol serving the 
particular user, as well as an indicator as to whether the 
user is registering as an individual or group address. 

In a similar manner, a user may deregister with the 
Local Control Function, or become inactive, by send- 
ing a Deregister command to the Registry. 

Programs use the Registry for finding partner pro- 
grams. For example, if a particular program wished to 
communicate with a program utilizing USER 1 (shown 
in FIG, 4), it could, from the information in the Regis- 



Address resolution service 25 (FIG; 1) may comprise 
one or more multi-protocol Address Registry which 
includes every user address that can be accessed over 
the transport protocols it serves. In some cases, address 35 
resolution service can be provided without an Address 
Registry. For example, if only minimal services are 
required and the transport user address space is more 
constrained than the provider's address, an algorithmic 
mapping can be used between the two. This can be 40 
done, for example with IP user addresses and SNA 
provider addresses. Likewise, some network directories 
can be extended to support additional address types; 
when these networks act as providers, they are capable 
of providing address resolution services. 45 

The remainder of this specification assumes that a 
registry is in use even when other methods are avail- 
able. Within the Registry, each user address is associ- 
ated with the transport provider addresses that can be 
used to access it An example of a multi-protocol Ad- 50 
dress Registry is shown in FIG. 4 where each user 
(USER 1, USER 2, USER 3 and USER Z) has a user 
identifier having a "TYPE" field for identifying the 
particular protocol it conforms to and a user identifier 
("USER 1", etc.) and one or more provider addresses, 55 
depending upon how many protocols each user is sup- 
ported by, each having a provider identifier field. For 
instance, USER 1 is supported by PROTOCOL 1 and 
PROTOCOL 2 and, therefore, has two different pro- 



This process can be employed in one particular net- 
work type or between two or more network types. For 
example, where there are two networks Nl and N2 of 
different types (for example, TCP/IP and OSI). Con- 
nected by a gateway, using the present invention, a 
program at a node in NI employing an SNA user (for 
instance) may communicate over a TCP/IP network 
Nl to an OSI network N2 via gateway to a partner 
program at anode in N2 being also being serviced by an 
SNA user. This is accomplished by having a registry 
servicing each network. 

The process by which the program addresses are 
registered and deregistered and are subsequently lo- 
cated can be thought of as involving four separate pro- 
cedures. First (FIG. 5), the Local Control Function 
controls the individual and group address registration/- 
deregistration of its respective programs by communi- 
cating with its Users and the Registry. Second (FIG. 6), 
the Registry communicates with various local control 
functions as well as gateways for registering and dereg- 
istering addresses. Third (FIG. 7), the Local Control 
Function establishes connections and sends/receives 
datagrams with partner programs. Fourth (FIG. 8), the 
Registry communicates with local control functions 
and gateways for connecting or conveying datagrams 
between partner programs. FIGS. 5, 6, 7 and 8 are 
shown at a high level and corresponding figures (FIGS. 
5A, 5B, 5C, 5D, 5E, 5F and 5G; FIGS. 6A, 6B, 6C, 6D 



vider IDs (PROVi and PROVj). USER Z, on the other 60 and 6E; FIGS. 7A, 7B, 7C, 7D and 7E; FIGS. 8A and 
hand; is supported by all three protocols, PROTOCOL 



1, PROTOCOL 2, and PROTOCOL Z and therefore 
has three different provider IDs, one of each protocol 
type. 

The Address Registry is dynamically updated with 65 
the addresses of programs which become available to 
the MPTN. Address resolution services 25 associates 
the transport user with at least one transport provider 



8B, respectively) show greater detail. 

Address Registration/Deregistration 

In FIG. 5, initially, the Local Control Function re- 
ceives a request for service from the Transport User 
(User), the Address Registry (via the transport Pro- 
vider), or the Transport Provider itself (if an additional 
Provider is being added at the node) at step 60 and the 
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Local Control Function determines which message is algorithm is used to map the User to the Provider or 

received. If the message is a Register request from the where there is a native directory in the network for 

User at step 62, the address registration process shown retrieving non-native names, eg., an extension to TCP's 

in FIG. 5A is invoked at "ER" (step 66). Domain Name Server (DNS) to treat the User's proto- 

If the request for service is a Deregister request from 5 col as a domain, 

a User at step 84, the Local Control Function deter- The Local Control Function then registers the ad- 

mines, at step 86, whether it is a group address or an dress by adding the provider address to the register 

mdividual address for further processing at "EDG" request for the appropriate address registry, at 116. The 

(step 88) or «EDR (step 90), respectively. Local Control Function then ensures that the program 

If the request for service is a reply to a Register re- 10 has an address registered for aU of the available trans- 
quest from the Address Registry at step 70, the Local at U g 

Control Function finds the associated request at step 72 Referringagain to FIG. 5, if the message is a deregis- 

to determine at step 74, whether it is a group address ^ reque st, at 84, for an individuaHddress at 8* 

(where "ERG2 " process of FIG 5E (at step 76) is m- 90 of FIG. SB is invoked. At 184, the Local 

voked), or whether it is an manual address at step 78 15 Control Function determines whether a native trans- 

faStan* PrOCeSS ° f 50 (at StCp 8 ° ) 15 Port Provider is available. If so, the protocol-specific 

t* *i. ^ f _ - j j • deregjstration mechanism is used at 186. The RegCtr 

voke J does not equal zero at 190, the process is complete. (As 
The address registration process ("ER" at step 66 of * ^ punting the number of pro- 
FIG. 5) is showTin greater detail in FIG.-5A. The 1 ~* U ^ U ^ » <f e £ ^ 
Local Control Function determines at 100 whether or ^^J* T^fT* ^ ^ 
not the native transport Provider to the program is £^F*f address 1 needs to * lef L m * e V 
available. If it is, a protocol-specific registration mecha- 25 ^gCtr does equal zero, and tihe address is dere^stered 
nism is used at 102. An example of a protocol-specific for "? non-native ^rx>rt Providers at 192, the pro- 
mechanism is where, in NetBIOS, the name to be regis- cess * complete. If the address has not been deregis- 
tered is broadcast to ensure that it is not being presently * red nonna ? ve transport Providers, the Local 
used by another. The Local Control Function then Co**** Function determines whether the next trans- 
determines whether the requester program is the first 30 P° n Provlder a protocol-specific address registra- 
with that User (program node-level) address at 104, for tion * m - Uso > at w > protocol-specific deregistra- 
example, the first T-selector with a particular OSI tion mechanism is used. The Local Control Function 
NSAP transport User. If not, the counter (Regctr) for builds a Reregister message with the program node- 
that address is incremented at 106 and the process is lcvel address ^ to the Registry at 198. The 
complete as that particular User address has already 35 ^ oca ^ Control Function ensures that the address has 
been registered at the Registry. If it is the first use, been deregistered for all non-native transports at 192 via 
Regctr is initialized at 108 and the registration process **EDRI" 200. 

continues. The counter is utilized so that the Local however, the message is a deregister request at 84 
Control Function may be able to maintain how many for a S^P address "EDGr" 88 of FIG. 5C is invoked, 
programs are using the particular User. The counter is 40 ^ a ^tive transport Provider is available at 202, the 
incremented for each new program using a particular protocol-specific mechanism for removing the program 
User registered at the Registry and is decremented for from the group is used at 204. The group size is decre- 
each program going inactive. When the counter reaches mented at 206 and, at 208, if the group size does not 
zero, the User address is removed from the Registry. equal zero, the process is complete. If the group size is 
At step 109, the Local Control Function creates a 45 zero* the Local Control Function determines whether 
<c blank" Register request for each Address Registry the group address has been deregistered for all non- 
with which the access node communicates as there may native transports at 210. If it has not, the protocol- 
be more than one Registry communicating with the specific means to quit the associated transport group is 
access node. A "blank" Register request has no trans- used at 212. A Deregister message is sent to the Registry 
port Providers therein. At 110, the Local Control Func- 50 with the program group address at 214. The Local 
tion determines whether the address is registered for all Control Function ensures that the group address has 
non-native transports which are available. If so, the been deregistered for all non-native transport Providers 
Local Control Function determines at 111 whether the at 210 via "EDG1" 216. 

Register requests for all of the Address Registries have Referring again to FIG. 5, where the message is a 

been processed. If so, the registration process is com- 55 reply to a Register request from the Registry and is for 

plete. If not, the Local Control Function determines, at a group address (at "ERG2" 76), the Local Control 

113, whether the next Register request has any trans- Function determines whether the Register reply is posi- 

port Providers included. If so, Local Control Function rive or negative at 138 in FIG. 5E. If negative, i.e., the 

sends the Register request to the next Address Registry address is used by another in the network, the Local 

at 115 and returns to 111 to ensure that the Register 60 Control Function undoes all previous registrations (na- 

request has been processed for all Address Registries. tive and non-native) and returns GroupCtr to **0" at 

If all useable transport Providers have not been pro- 140. If it is positive, Local Control Function uses the 

cessed at 110, the Local Control Function determines protocol-specific mechanism to join group for each 

whether the next transport Provider to be registered returned transport group address at 142. Transport 

with the program is served by a protocol-specific mech- 65 Providers have functions that need to be invoked in 

anism at 112. If so, the address is registered using this order to join a group. This may be as simple as setting 

mechanism at 114. Examples of protocol-specific mech- an entry in a table that indicates that this value should 

anisms which support a transport protocol are where an be accepted. The Local Control Function then ensures 
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that the address is registered for all non-native transport dress Registry sends a message to one gateway about 
Providers at 130 as discussed above, the new network identifier and initializes the NETID 

Where the message is a reply from the Registry and is USE counter to "1" at 364. If the network identifier in 
for an individual address (at "ER2" 80), Local Control the program address is not new to the Registry at 362, 
Function, at 146 in FIG. 5D, determines whether the 5 the Address Registry increments the NETID _ USE 
reply is positive (if so, go to **ER1" 118 at FIG. 5 A) or counter at 366. Because some gateways may be con- 
negative where the Local Control Function undoes all nected between more than two networks, each gateway 
previous registrations and returns RegCtr to "0". must maintain which networks it is responsible for. This 

Where the request for service in FIG. 5 is a request is done via the network ID. The NETIDUSE counter is 
from a Transport Provider to be added for service by 10 used for keeping track of the number of active programs 
the Local Control Function, "ERT" 71 of FIG. 5F is per network so that when there are no active programs 
invoked. At 73, the Local Control Function determines for a particular network, the gateway may be able to 
whether all registered addresses have been processed. If deregister the network. 

so, the process is complete. If there is a registered ad- "RGR" 306 is illustrated in FIG. 6B. If the group 
dress not processed, and the new transport Provider is 15 address is already in the Registry as a group address at 
native to that address at 75, the protocol-specific regis- 368, the Address Registry initializes the New Provider 
tration mechanism is used at 77. If the new transport is Address list to zero at 367 and determines whether all 
served by a protocol-specific mechanism at 79, the ad- of the supported transports for that group have been 
dress is registered using this mechanism at 81. The registered at 369. If not, at 371 it is determined whether 
Local Control Function sends a Register message to the 20 the next transport Provider is in the directory. If it is, 
Registry with the program node-level address and the the group size is incremented at 370. If not, the Registry 
transport node address for this transport Provider at 83. generates a transport group address for this transport, 

Referring now to FIG. 6, the procedure which the initializes the GroupSize to 1, and increments the New- 
Address Registry utilizes for address registration/- ProviderAddressList at 384. If the list of supported 
deregistration is shown at a high level. Initially, the 25 protocols is complete at 369, the Registry determines 
Address Registry receives a message from the access whether the New-Provider —AddressList is equal to 
node or a gateway at 300. If the message is a request to zero at 373. If it is, a positive reply for the Register 
register from an access node at 302, the Address Regis- request with the assigned transport group addresses is 
try determines whether it is a request to register a group sent at 392. If not, it is determined whether gateways 
address or an individual address at 304. If it is a group 30 are supported at 386. If they are, the Registry sends the 
address, "RGR" 306 in FIG. 6B is invoked. If it is a transport addresses to the corresponding gateways. If 
request to register an individual address, "RR" 308 in they are not supported, the Registry enters the program 
FIG. 6A is invoked. address and associated transport address(es) in the Reg- 

If the message is a request to deregister from an ac- istry at 390 and sends a positive reply at 392 as discussed 
cess node at 310, the Address Registry similarly deter- 35 above. 

mines whether the address to be deregistered is a group If, at 368, the address is not in the Registry as a group 
address, wherein "RGD" 314 shown in FIG, 6D is address but it is in the Registry as an individual address 
invoked, or an individual address wherein "RD" 316 of at 374, a Fail Register Request is returned at 376. If the 
FIG. 6C is invoked. address is not in the Registry as an individual address at 

If the message is an Address Verification Reply from 40 374, and verification is not required at 378, the New— 
a gateway at 332, the Address Registry finds the regis- Provider— Address_List is initialized at 367 as dis- 
ter request at 334 and invokes "RAV" 336 shown in cussed above. If verification is required at 378, and the 
FIG. 6E. network is split at 380, the Address Registry sends an 

If the message is not an Address Verification Reply address verification message to a gateway that can 
from a gateway at 332 but rather a Group Address 45 reach the split network at 382. 
Reply at 338, the Address Registry finds the register "RD" 316, the individual address deregistration pro- 
request at 340 and invokes "RGR1" 342 shown in FIG. cedure, is illustrated in FIG. 6C The Address Registry 
66. checks to see if the address is in the Registry at 394. If 

Referring now to FIG. 6A, "RR" 308 is illustrated. If it is, it deletes the entry from the Registry at 396, decre- 
the address is already in the Registry at 350, the Ad- 50 ments the NETID— USE counter at 398, and deter- 
dress Registry sends a negative reply to the access node w"iif3 whether the NETID— USE counter is equal to 
at 356 indicating that another User has registered under zero at 400. If it is, the Address Registry sends an NE- 
that address. For some protocols, such as NetBIOS, TID-NO-LONGER-IN-USE message to the gateway 
explicit verification of the address is required. If a verifi- at 402 so that the gateway can remove the particular 
cation is required at 348, and the network is split at 352, 55 network from its own directory, 
the Address Registry sends an address verification mes- If the address to be deregistered is a group address at 
sage to a gateway that can reach the split network at 314 in FIGS. 6 and 6D, and the address is in the Regis- 
354. Where a network is split, interconnected by one or try at 404, the Address Registry decrements the group 
more gateways, all portions of the network must be size at 406 and determines whether the group size is 
verified so that there is no addressing redundancies as 60 equal to zero at 408. If it is, the Address Registry deletes 
the same network ID is used for all portions of the split the entry from the Registry and sends a GROUP-NO- 
network. LONGER-IN-USE message to the gateway at 410 so 

If the network is not split at 352 or verification is not that the gateway can remove the group from its direc- 
required at 348, the Address Registry enters the pro- tory. It then decrements the NETIDUSE field and 
gram address and associated transport address or ad- 65 processes the NETID at 411 in FIG. 6C to remove the 
dresses in the Registry and sends a positive reply for the NETED if needed. 

register message at 360. If the network identifier in the If the message is an Address Verification Reply at 332 
program address is new to the Registry at 362, the Ad- in FIG. 6, the Address Registry finds the register re- 



05/24/2004, EAST Version: 1.4.1 



quest at 334, invokes "RAV" 336 shown in FIG. 6E. If 
the address to be verified is identified in the register 
request as a Group Address at 442, the Address Regis- 
try determines whether the reply indicates that the 
address is already in use as an individual address else- 5 
where in the network at 444. If it is, it sends a negative 
reply to the access node 446 indicating to the Local 
Control Function that the ID requested is already in 
use. If it is not, "RGR1" 342, to be discussed below, is 
invoked. If the address to be verified is identified as an 10 
individual address at 442, and the reply indicates that 
the address is already in use as either a group or individ- 
ual address at 448, the Address Registry sends a nega- 
tive reply to the access node at 446. If the address is not 
already in use at 448, "RRT 358 shown in FIG. 6A as 15 
discussed above, is invoked. 

If, in FIG. 6, the message is a Group Address Reply 
from a gateway at 338, the Address Register finds the 
Register Request at 340 and invokes "RGR1" at 342 
(FIG. 6B). At 390, the Address Register enters the 20 
group address and associated transport addresses) in 
the Registry. 

Establishment of Connection/Conveyance of 

Datagram ^ 

FIGS. 7 and 8 illustrate the high level logic corre- 
sponding with the establishment of a connection and the 
conveyance of a datagram between partner programs. 
FIG. 7 corresponds to the logic within the Local Con- 
trol Function while FIG. 8 corresponds to the logic 30 
within the Address Registry. 

As shown in FIG. 7, if the request for service is an 
outgoing connect or datagram from a User at 92, "EC" 
process at 94 is invoked (FIG. 7A). If the request for 
service is an incoming connect or datagram from a 35 
transport at 96, "EI" is invoked at 98 (FIG. 7B). 

If the request is a reply to a Locate request from the 
Registry at 70, the Local Control Function invokes 
"EC3" at 82 (FIG. 7Q. The Local Control Function 
determines whether the Locate was successful at 150. 40 
(A "Locate" command is used by the Local Control 
Function when it needs to locate a partner program so 
that a connection may be made or a diagram sent there- 
between.) If it was, process "EC4" 152 of FIG. 7E is 
invoked. This will be discussed in greater detail below. 45 
If it was unsuccessful, the Local Control Function de- 
termines, at 154, whether the transport has protocol- 
specific mapping, Le., algorithmic or native directory. If 
it does, at 156, the Local Control Function invokes the 
protocol-specific address mapping to get destination 50 
node address. If it does not, "EC2" 172 of FIG. 7D (to 
be discussed in greater detail) is invoked wherein other 
transports, if any, are tried. Likewise, if the address is 
not found at 158, "EC2" 172 in FIG. 7D is invoked 

If the destination address is found, "EC4" 152 in FIG, 55 
7E is invoked. At "EC4" 152, the Local Control Func- 
tion converts the node-level transport (User) address to 
a complete transport address by adding the "well- 
known local ID" for non-native services at 162. The 
well-known local ED is a uni que ID used by the MPTN 60 
to indicate to another MFTN access node that MFTN is 
being used. The well-known local ID is understood by 
the Provider and used to do local routing at the destina- 
tion. Particular messages, and the respective message 
formats, will be discussed below. 65 

If a datagram at 164 is to be sent, the Local Control 
Function builds an MFTN datagram that carries pro- 
gram addresses and sends the datagram using the se- 
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lected transport protocol and derived transport address 
at 166. If it is not a datagram, i.e., it is a connection, the 
Local Control Function uses the derived destination 
transport address to open a connection for the selected 
transport at 168. If the connection setup is not success- 
ful at 170, "EC2" 172, discussed below, is invoked. If it 
is successful, the Local Control Function sends the 
MPTN Connect message with the application addresses 
as the first message on the connection and receives the 
MPTN Connect reply at 174. This message is data to 
the provider. If the MPTN Connect reply is positive at 
176, the process is complete. If not, "EC2" 172 is in- 
voked. 

"EC2" 172 is shown in FIG. 7D. The Local Control 
Function determines whether there are any transports 
in the transport User's connection preference list left to 
try at 178. If not, Local Control Function "fails" the 
request at 180. If so, the Local Control Function deter- 
mines, at 181, whether there is an Address Registry 
(sometimes an Address Registry is not used). If there is 
no Address Registry available, W EC5" 183 of FIG. 7C 
as discussed above is invoked. If an Address Registry 
that serves the next transport is available, the Local 
Control Function sends a Locate message at 18Z 

Referring again to FIG. 7, if the request for service is 
an outgoing connect or datagram from a User program 
at 92, "EC at FIG. 7A is invoked to determine 
whether native services can be used. If the source ad- 
dress and the destination address do not have matching 
address types at 218, "EC1" 220 of FIG. 7C is invoked 
as discussed above. If they do, the Local Control Func- 
tion determines whether there is a transport available 
that uses the same address type as the source address at 
222 and, if not, "EOT 220 is invoked. If so, the Local 
Control Function determines whether the program uses 
transport features that require MPTN headers to be 
inserted in the data stream if run over this transport at 
224. If so, "EC1" 220 is invoked. If not, the program 
address is used as a transport address and the protocol- 
specific connection or datagram protocol is used at 226. 

If the request for service is an incoming Connect 
message or datagram from the transport at 96 in FIG. 7, 
"EI" 98 in FIG. 7B is invoked. If the transport address 
does not include the local address used for non-native 
services at 228, i.e., if the transport address does not 
include the well-known local ID used for MPTN com- 
munication only, the program is native to the Provider 
and program addresses are set to be the transport ad- 
dresses at 230 and "Ell" 232 is invoked. "Ell" 232 is 
the portion of the procedure where the destination ad- 
dress is examined for recognition to be discussed below. 
Local control function determines whether it is a data- 
gram at 234. If it is, the program addresses are extracted 
from the non-native datagram format for the User's 
datagram at 236 and "Ell" 232 is invoked. If it is not a 
datagram, the protocol-specific establishment is com- 
pleted, the non-native Connect message is received as 
the first packet, and the source and destination program 
addresses are extracted from the Connect message at 
238. At 240 (or "Ell" at 232), the destination program 
address is examined for recognition. If it is not recog- 
nized, the connection request is failed or the datagram is 
thrown away at 242. If it is recognized, at 244, the con- 
nection processing is completed or the diagram is deliv- 
ered to the program identified by the destination pro- 
gram address, providing it with the source program 
address so that it knows where it came from. 
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Referring now to FIG. 8, the logic used by the Ad- or message, (i.e., Register, Connect, or Locate). DLC 
dress Registry for setting up a connection or sending a and Provider message formatting is well known in the 
datagram is shown. Initially, a message is received from art and will not be described here, 
an access node or gateway at 300. If the message is a During message exchange through the between the 
Locate request from an access node at 318, "RL" 320 5 MPTN network components, the DLC header and 
shown in FIG. 8 A is invoked. If the message is a Locate trailer is stripped away by the particular protocol being 
request from a gateway at 322, "RLG" 324 of FIG. 8B used, and, similarly, the Provider header is stripped off 
is invoked If the Address Registry determines that it is by the transport Provider. 

a Locate reply from a gateway at 326 in FIG. 8, "RL1" FIG. 10 illustrates the MPTN command format for a 
328 shown in FIG. 8A is invoked. 10 stream Provider, such as TCP/IP. This format consists 

If, in FIG. 8A, the destination program address is not of a five-byte field representing the overall command 
registered in> the Address Registry at 412, the Address length followed by a variable length field representing 
Registry determines whether the network is part of a the actual MPTN command. The MPTN command 
split network or whether the Net— Id identifies a non- format for record transport Providers, e.g., SNA, OSI 
local network at 413. If not, a "fail" response is re- 15 and NetBIOS, has only the MPTN command and not 
turned. If so, the Address Registry determines whether the command length field. 

there is a gateway at 415. If not, a "fail" response is There are several commands which will be described: 
returned. If so, the Registry determines, at 417, whether Connect, Register and Locate (and associated Discon- 
there is a gateway and, if so, sends a Locate message to nect and Deregister). FIG. 10 shows the command 
the gateway at 414 for deterrnining whether the destina- 20 format for the Connect command. This format is used 
tion program address may be located in other networks for the Connect request, as well as the positive and 
or in the other portion of the split network. If the desti- negative replies. The Connect command format consists 
nation program address is registered in the Address of six required fields: (1) a prefix field (FIG. 11), which 
Registry at 412, the Address Registry determines at 423 is a standard prefix used for all MPTN commands; (2) a 
and 425 the most preferred Provider remaining in the 25 User transport request field (FIG. 12), which is a set of 
source transport User's Preference connection list At transport characteristics requested by the transport 
427, the Address Registry determines whether the desti- User; (3) a service mode field (FIG. 13), which repre- 
nation transport User is supported by this Provider. If sents the level of transport search required; (4) a User 
so, the destination transport address is returned to the connection data field, which represents transport User 
access node at 421. If not, the Address Registry deter- 30 connection data (for example, an SNA transport User 
mines whether there are any transport Providers re- may send a BIND image to a destination transport 
maining in the source transport User's preference list at User); (5) a compensation required field, which repre- 
423. If not, a "Not Found" acknowledgement is re- sents the types of compensation that will be used on this 
turned to the end node at 420. connection (this is discussed in greater detail in com- 

If, at 322 in FIG. 8, the message is a Locate message 35 monly assigned, co-pending patent application Ser. No. 
from a gateway, "RLG" 324 in FIG. 8B is invoked. If, 07/731,564>, and (6) a diagnostics field (FIG. 14), which 
in FIG. 8B, the destination program address is not regis- represents the reason for failure on a negative reply, 
tered in the Address Registry, a "Not Found" acknowl- The first two fields, the prefix and User transport re- 
edgement is returned to the gateway at 425. If it is quest fields, are required fields, while the remaining 
found, the Address Registry determines whether there 40 four fields are optional. Additional optional fields can 
is a transport address in the Registry that appears in the be added by Gateways. 

list of transport protocols supported by the gateway Referring now to FIG. 11, the format for the prefix 
node at 428. If not, a "Not Found" acknowledgement is field as illustrated in FIG. 10 is shown. The prefix field 
returned to the gateway at 426. If so, the destination consists of six individual fields: (1) a single byte corn- 
transport address is returned to the gateway at 430. 45 mand type field representing the type of command for- 
If, at 326 in FIG. 8, the Address Registry determines mat; (2) a single byte command migration specification 
that it is a Locate reply from a gateway, "RLI" 328 of field representing instructions to the destination trans- 
FIG. 8A is invoked. If the address cannot be found by port User about how to handle if the command type if 
the Address Registry at 422, the Address Registry re- unknown; (3) a single byte TTL field for use by Gate- 
turns a "Not Found" acknowledgement to the end node 50 ways to prevent indefinite looping; (4) a destination 
at 420 as discussed above. If it is found, the Address transport User address field, a variable length field rep- 
Registry determines whether it is the transport address resenting the destination transport User address; (5) a 
in the Registry or returned by the gateway that appears source transport User address field, a variable length 
in a list of transport protocols supported by the source field representing the source transport User address; 
end node at 412 as discussed above. 55 and (6) a correlator suffix field which is a unique identi- 

i/TrrvT it , t-, ^ fier for this connection. 

MPTN Message/Command Formats FIG. 12 illustrates the User transport request field as 

FIGS. 9 through 19 are graphical representations of illustrated in FIG. 10. The User transport request field 
the particular message formats for messages exchanged consists of six fields: (1) a single byte LEN field which 
in an MPTN. FIG. 9 shows a basic link unit (BLU) 60 represents the length of the User transport request, 
format which is routed throughout a computing net- including the length field; (2) a TSDU field, which 
work, between MPTN Access Nodes, MPTN Address represents the maximum record size (this four byte field 
Registries and MPTN Gateways. The BLU includes a is equal to zero for a stream Provider); (3) an ETSDU 
Data Link Control (DLC) header and trailer for format- field, a four byte field representing the mnTtmnm expe- 
ting as is well known in the art An example of a format 65 dited message (this field is equal to zero if expedited 
is Synchronous Data Link Control (SDLC). The BLU communication is not used); (4) a DISCON field, a four 
also includes a Provider header for the particular trans- byte field representing the maTimnm size of the tennina- 
port Provider being utilized and the MPTN command, tion data, e.g., UNBIND for an SNA transport Pro- 



05/24/2004, EAST Version: 1.4.1 



ft «l 



5,425,028 

: - - - 17 - 18 

vider (this four byte field is equal to zero if termination User address are group addresses that require transport 

data is not used); (5) a termination types field represent- addresses to be returned; (5) a variable length correlator 

ing the types of termination used (this is discussed in field (FIG. 18) which is a unique identifier that connects 

commonly assigned, co-pending patent application Ser. all related address management commands; (6) a van- 

No. 07/731,564); and (6) an expedited marking field as 5 able length User address field (FIG. 19) for representing 

discussed in co-pending patent application Ser. No. the transport User addresses to be registered; and (7) a 

07/731,564. variable length Provider address field representing the 

FIG. 13 illustrates the service mode field of the Con- transport Provider addresses that the User addresses are 

nect command illustrated in FIG. 10. The service mode to be mapped to. 

field includes two fields: (1) an MPTN mode field repre- 10 Referring now to FIG. 18, the correlator field as 
senting the standard MPTN service mode to use if the identified in FIG. 17 is shown. The correlator field 
User defined mode is not given or not understood (for consists of two individual fields: an LCF address field 
example, by Gateway); and (2) a User defined mode which represents the address of the MPTN local con- 
field of a variable length representing a User defined trol function that initiated this procedure and a correla- 
service mode. 15 tor suffix field which represents a unique identifier for 

FIG. 14 illustrates the diagnostics data field of the this procedure. 
Connect command as illustrated in FIG. 10. The diag- FIG. 19 illustrates the address list field which format 
nostics data field, which is only used for negative replies is used in the User address field and Provider address 
indicating some sort of error, consists of four fields: (1) field of the EA-Register command of FIG. 17. The 
a four-byte primary return code field indicating a gen- 20 address list field of FIG. 19 consists of three fields: (1) a 
eral failure category; (2) a four-byte secondary return three byte length field representing the length of the list; 
code field representing a more detailed classification of (2) a single byte count field representing the number of 
a failure; (3) an error detector field of variable length addresses that follow; and (3) a variable length address 
representing the address of the component detecting or field representing a number of addresses (indicated in 
generating the error; and (4) an error data field of van- 25 the count field), either transport User address or trans- 
able length describing the error in more detail. port Provider addresses. 

FIG. 15 illustrates an MPTN datagrammessage for- FIGS. 10-19 have illustrated example formats for a 
mat The MPTN datagram format consists of eight number of commands, i.e., Connect, MPTN Datagram 
fields: (1) a variable length prefix field which is shown and Register, and these particular formats are not re- 
in FIG. 12 and described in detail above; (2) a two byte 30 quired for the present invention. The formats for the 
command length field representing the length of the remaining commands are quite similar and, with the 
MPTN datagram header; (3) a single byte retry field information provided, one of ordinary skill in the art 
which indicates whether Gateways should use their may configure the remaining command formats in a 
caches for routing this datagram; (4) a variable length similar manner. 

service mode field shown and described above in FIG. 35 While the invention has been particularly shown and 

13 and corresponding text; (5) a source Provider ad- described with reference to preferred embodiments 

dress field* representing the non-standard address that thereof, it will be understood by those skilled in the art 

the source transport Provider wants to use to receive that various other changes in form and detail may be 

datagrams; (6) a variable length destination Provider made without departing from the spirit and scope of the 

address, a non-standard address that the destination 40 invention, 

transport Provider want to use to receive datagrams; (7) What is claimed is; 

a twelve byte segment spec field (FIG. 16) which is 1. A method of establishing proper addressing in a 

used by the destination local control function to reas- first node so that transport-level communication may be 

semble the datagram segments (if the datagram is seg- established across a network between a source transport 

mented); (8) a variable length User datagram, a binary 45 User in said first node and a destination transport User 

string representing the actual User datagram. Of these in a second node, said source transport User having a 

eight fields, the service mode field, the source Provider first address and a first addressing format and being 

address field, the destination Provider address field, and supported by a plurality of source transport Providers 

the segment spec field are optional fields. in said first node at the interface to the network, said 

FIG. 16 illustrates the segment spec field of the 50 destination transport User having a second address and 
MPTN datagram format of FIG. 15. The segment spec a second addressing format and being supported by a 
field consists of a four byte User datagram length field plurality of destination transport Providers in said sec- 
representing the length of the entire datagram, and a ond node at the interface to the network, each of said 
four byte segment offset field representing the position source and destination transport Providers having 
of this segment in the datagram so that the destination 55 unique address from each other and from said transport 
local control function can properly reposition the seg- Users and an addressing format different from said 
mented datagram. transport Users, said method comprising the steps of: 

FIG. 17 illustrates the Register command when sent (a) in said first node, identifying a source transport 

from an Access Node to an Address Registry. This User requesting to establish communication with a 

Register command is denoted as "EA-Register" to dis- 60 destination transport User; 

tinguish from other Register commands. The EA-Reg- (b) in said first node, identifying said requested desti- 

ister command comprises seven fields: (1) a variable nation transport User; 

length prefix field (FIG. 11), which, as discussed above, (c) in said first node, identifying one or more of said 

is a standard prefix used for all MPTN commands; (2) a plurality of source transport Providers, in said first 

single-byte verification field for those transport Provid- 65 node, which support said source transport User; 

ers (Le., NetBIOS) which require verification; (3) a (d) identifying one or more of said plurality of desti- 

single-byte open field for later use; (4) a single-byte nation transport Providers, in said second node, 

address assignment field for representing whether the which support said destination transport User; and 
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(e) identifying a common transport protocol sup- 
ported by a source transport Provider, in said first 
node, which supports said source transport User 
and further supported by a destination transport 
Provider, in said second node, which supports said 
destination transport User. 

2. The method as defined in claim 1 further compris- 
ing, after step (e), step (f) of, where there are a plurality 
of common transport protocols, each transport protocol 
having a total compensation effort weight, said total 
compensation effort weight being a measure of the total 
effort required to provide compensation between said 
source transport User and said source transport Pro- 
vider, selecting the transport protocol with the least 
total compensation effort weight 

3. A method of establishing transport-level communi- 
cation between a source transport User in a first node 
and a destination transport User in a second node, said 
source transport User having a first addressing format 
and being supported by a plurality of source transport 20 
Providers in said first node at the interface to the net- 
work, one or more of said plurality of source transport 
Providers having a second addressing format, said desti- 
nation transport User having a third addressing format 
and being supported by a plurality of destination trans- 25 
port Providers at said second node at the interface to 
the network, said method comprising the steps of: 

(a) in said first node, identifying a source transport 
User in said first node requesting to establish com- 
munication with a destination transport User in 30 
said second node; 

(b) in said first node, identifying said requested desti- 
nation transport User in said second node; 

(c) determining whether said source transport User 
and said destination transport User have the same 35 
addressing formats; 

(d) if so, in said first node, determining whether a 
source transport Provider is available that uses said 
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tion across a network with a destination transport User, 
at a second node, having said first addressing format 
and being supported by a plurality of destination trans- 
port Providers in said second node, may locate said 
destination transport User, at least one of said source 
transport Providers and at least one of said destination 
transport Providers having a second addressing format, 
said second addressing format being different from said 
first addressing format, said method comprising the 
steps of: 

(a) receiving a request from said transport User for 
registering said transport User for communication 
through said network: 

(b) determining the available transport Providers 
having said second addressing format for which 
said transport User has not yet been registered; and 

(c) sending a message to said network address resolu- 
tion service unit for registering said transport User 
with said transport User address and said transport 
Provider address of an available, unregistered 
transport Provider having said second addressing 
format 

7. The method of registering a transport User as de- 
fined in claim 6 further comprising, after step (b), the 
step (bl) of determining whether a transport Provider 
which is native to said transport User is available and 
the step (b2) of, if so, using a protocol-specific mecha- 
nism for registering said transport User address. 

8. The method of registering a transport User as de- 
fined in claim 6 or claim 7 further comprising the step 
(d) of repeating step (b) through step (c) until said trans- 
port User has been registered for all available transport 
Providers. 

9. A system in a node for establishing proper address- 
ing so that transport-level communication may be estab- 
lished across a network between a source transport 
User in said first node and a destination transport User 
in a second node, said source transport User having a 



same addressing format: and 
(e) if so, using said source transport Provider for 40 ^ rst address and a first addressing format and being 
establishing a connection between said source supported by a plurality of source transport Providers 
transport User and said destination transport User. m firs* node at the interface to the network, said 
4. The method of establishing communication defined destination transport User having a second address and 
in claim 3 wherein the method further comprises, after a second addressing format and being supported by a 
step (d), the step (dl ) of, if not, determining whether a 45 plurality of destination transport Providers in a second 
source transport Provider, in said first node, is available node at the interface to the network, each of said source 
which has protocol-specific address mapping, the step and destination transport Providers having unique ad- 
(d2) of, if so, attempting to use said protocol-specific dress from each other and from said transport Users and 
address mapping to obtain a destination transport Pro- 811 addressing format different from said transport Us- 
vider address, step (d3) of, if not successful, determining 50 era, said system comprising: 



whether another source transport Provider, in said first 
node, is available which has protocol-specific address 
mapping, and step (d4) of, if so, repeating step (62). 

5. The method of establishing communication defined 

in claims 3 or 4 wherein step (b) further comprises de- 55 
termining whether said destination transport User is 
recognized, and further wherein the method further 
comprises the step (f) of completing the establishment 
of the communication if said destination transport User 
is recognized. 

6. A method of registering a transport User, having a 
unique transport User address, for a plurality of trans- 
port Providers, each having a unique transport Pro- 
vider address, with a network address resolution service 
unit so that a source transport User, at a first node, 
having a first addressing format and being supported by 
a plurality of source transport Providers in said first 
node, wishing to establish transport-level communica- 
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(a) means, in said first node, for identifying a source 
transport User requesting to establish communica- 
tion with a destination transport User; 

(b) means, in said first node, for identifying said re- 
quested destination transport User; 

(c) means for identifying one or more of said plurality 
of source transport Providers, in said first node, 
which support said source transport User, 

(d) means for identifying one or more of said plurality 
of destination transport Providers, in said second 
node, which support said destination transport 
User; and 

(e) means for identifying a common transport proto- 
col supported by a source transport Provider, in 
said first node, which supports said source trans- 
port User and further supported by a destination 
transport Provider, in said second node, which 
supports said destination transport User. 
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10. The system as defined in claim 9, where there are 15. The system defined in claims 13 or 14 wherein 
a plurality of common transport protocols, each trans- said destination transport User identification means 
port protocol having a total compensation effort further comprises means for determining whether said 
weight, said total compensation effort weight being a destination transport User is recognized, and further 
measure of the total effort required to provide compen- 5 wherein the system further comprises means for com- 
sation between said source transport User and said pleting the establishment of the communication if said 
source transport Provider, said system further compris- destination transport User is recognized. 

ing means for selecting the transport protocol with the 16. The system defined in claims 13 or 14 wherein 
least total compensation effort weight said source transport User is located at a first access 

11. The system as defined in claims 9 or 10 wherein 10 node and said destination transport User is located at a 
said source transport User is located at a first access second access node and further wherein said common 
node and said destination transport User is located at a transport Provider identification means comprises an 
second access node and further wherein said common address registry. 

transport Provider identification means comprises an 17 - A system for registering a transport User at a first 
address registry. * 5 node, said transport User having a unique transport 

12. The system as defined in claim 11 wherein said User for a plurality of transport Providers at 
first access node is part of a first multi-protocol trans- ^ d node » ^ a unique transport Provider 
port network (MPTN) and said second access node is address, with a network address resolution service unit 
part of a second MPTN, said MPTNs being connected so that a source transport User having a first addressing 
by a gateway 20 format and being supported by said one or more trans- 

13. In a system for conveying transport-level commu- P°* Providers in said first node at an interface to the 
nication between a source transport User in a first node n€ *? 0Tk > v ^ hm ^ to establish transport-level communi- 
and a destination transport Userin another node, said «*» a network witha destination transport 
source transport User having a first addressing format „ J^F at 'J"* ^ ?*d destination transport User 
0 * ^ ^ . 0 i:-, „ f Mnw%t > JL„c~^vr+ 25 having said first addressing format being supported by 

iS^ ^ said one or more transport Providers m said second 

Providers in said first node, at the mterface to the > net- nQd&at *n interface to Ae network, and so that said 
work, one or more of said source transport providers ^ User ]ocate destination ^ 

having a second addressing format, said destination ^ Jfc^ Qne of 4 dtransport fa|>id 

transport User having a third addressing format and ^ ^ node having a second addressing format, said sec- 
being supported by a plurahty of destination transport ^ ^drcssmz format being (£t from said first 
Providers, in said another node, at another mterface to flH rfr^iti g format, said system comprising: 
the network, an apparatus for selecting one of said (a) meanS) m ^ ^ node , for receiving a request 
transport Providers for supportmg the commumcation fro m transport User, in said first node, for 

between said source transport User and said destination 35 registering said transport User for communication 
transport User, said apparatus comprising: through said network: 

(a) means, in said first node, for identifying a source (b) means, in said first node, for detennining the avail- 
transport User requesting to establish communica- able transport Providers, in said first node, having 
tion with a destination transport User, said second addressing format for which said trans- 

(b) means, in said first node, for identifying said re- 40 port User, in said first, node, has not yet been regis- 
quested destination transport User; tered; and 

(c) means for determining whether said source trans- ( c ) means, in said first node, for sending a message to 
port User and said destination transport User have said network address resolution service unit for 
the same addressing formats; registering said transport User, in said first node, 

(d) means for detennining whether a source transport 45 with said transport User address and the transport 
Provider, in said first node, is available that uses Provider address of an available, unregistered 
said same addressing format; and transport Provider, in said first, node, having said 

(e) means for selecting said source transport Provider second addressing format, 

for establishing a connection between said source 18. The system for registering a transport User as 
transport User and said destination transport User. 50 defined in claim 17 further comprising means for deter- 

14. The system defined in claim 13 wherein the sys- raining whether a transport Provider, in said first node, 
tern further comprises means for determining whether a which is native to said transport User, in said first node, 
source transport Provider is available which has proto- is available and means, in said first node, for using a 
col-specific address mapping, and means for selecting protocol-specific mechanism for registering said trans- 
said protocol-specific address mapping for obtaining 55 port User address. 

said destination transport User address. * * * * * 
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